Guidelines: Test Model
Topics
Explanation 
A test model is a model of what is to be tested in a target-of-test (be it the system or a part of the system). It is a view of the design and implementation models that include additional notation specific to test, including the test cases, test procedures, and test scripts. The role of the test model is to communicate what is to be tested and how to test it.
Use
For each iteration in the development lifecycle, you develop a new version of the test model. The new version should contain old tests (as regression tests), and new tests that take new functionality into account.
At the least detailed level of the test model, you will see the design and / or implementation model and notations reflecting the test cases. Test cases define a collection of inputs, execution conditions and expected results. The majority of the test cases are derived from use-case scenarios, or use-case realizations, and correspond to an execution of a use case as it traverses the test target. If the target-of-test is the whole system, the test case will correspond to a complete execution of a use case. If the target-of-test is a subsystem, the test case will correspond to the part of the use case that traverses the subsystem.
An example of a system test case for an ATM machine would be to verify that a customer can withdraw $100, provided the card is valid and enough funds are in the specified account. Another test case would be to verify that the ATM software behaves as expected when a customer enters the wrong PIN for an otherwise valid card.
In earlier iterations, there might not be any complete use-case descriptions yet, only scenarios. Therefore, in the first iteration of test, only a test case to verify the ability to withdraw cash is implemented, but not the ability to handle the wrong PIN code.
The most detailed of test models will depict the relationships between the test cases, test procedures, and the test scripts that are generated to execute the tests.
Not all requirements on a system are manifested in use cases. This type of requirement is referred to as non-functional or technical requirements. Examples are load requirements and application platform requirements.
A test case is derived from and traceable to a use case or scenario, a use-case realization, or a requirement.
In organizations where traceability from original system requirements to the details of the implementation is important (or required), a traceability link from a test case to its corresponding system requirement(s) should be maintained.
Note: if you do not have tools that efficiently help you maintain these
traceability links, it may become very costly to administer. In that case
knowing what use case, use-case scenario, or use-case realization a test case is
derived from may be sufficient.
At the highest level, your test cases should be grouped according to what the
target for test is: system, subsystem, or component. At the next level, you
might choose to group according to what use case or requirement the test cases
are derived from.
In a simple implementation, a test case is implemented as one test procedure.
The test procedure physically manifests itself as a textual instruction on how
to perform the test case (manual test), or as a test script to be executed
within the context of a test automation tool. In a more complex implementation,
a test case may correspond to one-to-many test procedures, as well as one test
procedure being part of implementing one-to-many test cases. Similarly, the test
procedures may be implemented by one-to-many test scripts.
See Artifacts: "Test Case", "Test Procedure", or "Test Script" for more information.
The relationship between test cases, test procedures, and test scripts.
A test case is implemented by one-to-many test procedures.
A test procedure may implement (the whole or parts of) one-to-many test cases.
When manual testing is to be executed, there is a one-to-one relationship with the test procedures.
When testing is automated (test scripts implemented), a test procedure may be implemented by many test scripts, or a test script may implement many test procedures (or parts of test procedures).
